If you roll out DevOps across an organization before it is culturally prepared for it, you will see warning signs that the initiative is failing. These are:

• Team members complain of unmanageable workloads
• Requirements, quality management and metrics get neglected; customer complaints increase
• You promote and reward the ‘firefighters’ rather than the staff who prevent bad things from happening.
• Your DevOps practices don’t work with ‘legacy’ technology.
• You have pockets of DevOps practice in just a few teams
• You feel the need to appoint specialist ‘DevOps’ people to sort out the issues
• You suddenly find that you’ve lost your testers
• Your developers talk more about NoOps than DevOps

What are the underlying causes of these painful symptoms? Lack of technical skills? Or of effective automation tools? In fact, it’s more likely to be ineffective teamworking. It is “soft skills”, not technical, tools or automation skills, that are the biggest factor in determining the ease or pain with which an organization can “switch to DevOps”.

This goes against many of our instincts as technologists. DevOps can seem at first to be another unruly aspect of the universe that can be fixed with technology. Bob Walker illustrates this admirably in his articles describing the introduction of DevOps to FCSA. The fun part was imagining the ability to “deploy to production 10 times a day ” and the technologies, cloud services, and the collaborative scripting, automation, monitoring tools that would help them get there. The hard part was defining their DevOps in a way that won support from all sides. Not everyone trusts the real motivation for such change.

So how can we achieve the hard part? Much is down to the old-fashioned arts of effective communication. As Grant Fritchey puts it, “Show what you’re learning. Show what you failed at. Show what you succeeded at. Share your knowledge with others.” Whereas other professions give training in such teamwork skills as communication, arbitration, empathy, compromise, and tactful persuasion, they are less in evidence in IT.

DevOps requires these teamwork and communication skills by the bucket load. If we can find better ways of facilitating communication within teams, then misunderstandings and tribalism as less likely to happen. Communication and coordination Tools such as Slack, Trello and Jira are evolving to the point of becoming the “operating system of the business”. Some operations teams are already using tools like Slack or HipChat to automate and document basic infrastructure changes, using bots and “slash commands“. The resulting text is and searchable and helps to explain to others not just what’s happening, but how and why. The automated processes can directly communicate their progress and outcome.

DevOps can make spectacular improvements in the speed and quality of the delivery of software, but it is the power of good teamwork and realistic workloads that makes it work. Sure, automation will help but it will only help an organization whose members are enabled to work cooperatively. It must support the teamwork and make the team processes more visible. Automation becomes the servant to the team, not its master.